<idor_vulnerability_guide>
<title>INSECURE DIRECT OBJECT REFERENCE (IDOR) - ELITE TECHNIQUES</title>

<critical>IDORs are among the HIGHEST IMPACT vulnerabilities - direct unauthorized data access and account takeover.</critical>

<discovery_techniques>
<parameter_analysis>
- Numeric IDs: user_id=123, account=456
- UUID/GUID patterns: id=550e8400-e29b-41d4-a716-446655440000
- Encoded IDs: Base64, hex, custom encoding
- Composite IDs: user-org-123-456, ACCT:2024:00123
- Hash-based IDs: Check if predictable (MD5 of sequential numbers)
- Object references in: URLs, POST bodies, headers, cookies, JWT tokens
</parameter_analysis>

<advanced_enumeration>
- Boundary values: 0, -1, null, empty string, max int
- Different formats: {% raw %}{"id":123} vs {"id":"123"}{% endraw %}
- ID patterns: increment, decrement, similar patterns
- Wildcard testing: *, %, _, all
- Array notation: id[]=123&id[]=456
</advanced_enumeration>
</discovery_techniques>

<high_value_targets>
- User profiles and PII
- Financial records/transactions
- Private messages/communications
- Medical records
- API keys/secrets
- Internal documents
- Admin functions
- Export endpoints
- Backup files
- Debug information
</high_value_targets>

<exploitation_techniques>
<direct_access>
Simple increment/decrement:
/api/user/123 → /api/user/124
/download?file=report_2024_01.pdf → report_2024_02.pdf
</direct_access>

<mass_enumeration>
Automate ID ranges:
for i in range(1, 10000):
    /api/user/{i}/data
</mass_enumeration>

<type_confusion>
- String where int expected: "123" vs 123
- Array where single value expected: [123] vs 123
- Object injection: {% raw %}{"id": {"$ne": null}}{% endraw %}
</type_confusion>
</exploitation_techniques>

<advanced_techniques>
<uuid_prediction>
- Time-based UUIDs (version 1): predictable timestamps
- Weak randomness in version 4
- Sequential UUID generation
</uuid_prediction>

<blind_idor>
- Side channel: response time, size differences
- Error message variations
- Boolean-based: exists vs not exists
</blind_idor>

<secondary_idor>
First get list of IDs, then access:
/api/users → [123, 456, 789]
/api/user/789/private-data
</secondary_idor>
</advanced_techniques>

<bypass_techniques>
<parameter_pollution>
?id=123&id=456 (takes last or first?)
?user_id=victim&user_id=attacker
</parameter_pollution>

<encoding_tricks>
- URL encode: %31%32%33
- Double encoding: %25%33%31
- Unicode: \u0031\u0032\u0033
</encoding_tricks>

<case_variation>
userId vs userid vs USERID vs UserId
</case_variation>

<format_switching>
/api/user.json?id=123
/api/user.xml?id=123
/api/user/123.json vs /api/user/123
</format_switching>
</bypass_techniques>

<special_contexts>
<graphql_idor>
Query batching and alias abuse:
query { u1: user(id: 123) { data } u2: user(id: 456) { data } }
</graphql_idor>

<websocket_idor>
Subscribe to other users' channels:
{% raw %}{"subscribe": "user_456_notifications"}{% endraw %}
</websocket_idor>

<file_path_idor>
../../../other_user/private.pdf
/files/user_123/../../user_456/data.csv
</file_path_idor>
</special_contexts>

<chaining_attacks>
- IDOR + XSS: Access and weaponize other users' data
- IDOR + CSRF: Force actions on discovered objects
- IDOR + SQLi: Extract all IDs then access
</chaining_attacks>

<validation>
To confirm IDOR:
1. Access data/function without authorization
2. Demonstrate data belongs to another user
3. Show consistent access pattern
4. Prove it's not intended functionality
5. Document security impact
</validation>

<false_positives>
NOT IDOR if:
- Public data by design
- Proper authorization checks
- Only affects own resources
- Rate limiting prevents exploitation
- Data is sanitized/limited
</false_positives>

<impact>
- Personal data exposure
- Financial information theft
- Account takeover
- Business data leak
- Compliance violations (GDPR, HIPAA)
</impact>

<pro_tips>
1. Test all ID parameters systematically
2. Look for patterns in IDs
3. Check export/download functions
4. Test different HTTP methods
5. Monitor for blind IDOR via timing
6. Check mobile APIs separately
7. Look for backup/debug endpoints
8. Test file path traversal
9. Automate enumeration carefully
10. Chain with other vulnerabilities
</pro_tips>

<remember>IDORs are about broken access control, not just guessable IDs. Even GUIDs can be vulnerable if disclosed elsewhere. Focus on high-impact data access.</remember>
</idor_vulnerability_guide>
